Your Data Stays Yours

The fastest way to get an AI answer is still the riskiest: paste an RFP, a pricing sheet, or an HR file into a personal chatbot and hope nobody notices. The work gets done. The data path does not belong to the business.

That is the problem Aida is designed around. Security is not a badge on a marketing page. It is how the product decides who can sign in, who can open a document, which files the assistant is allowed to read, and whether a form is open to the world or only to people with an account.

Aida treats your workspace as a governed system: encrypted in transit and at rest, isolated by tenant, and filtered by role before AI ever sees a page of your library.

Use AI on company work without handing company data to a tool you do not administer.

Security first with your data

Every customer’s workspace is its own tenant. Records are scoped to the business, so one company’s prompts, documents, and submissions are not searchable by another. That isolation is the floor, not the ceiling.

On top of it, Aida applies least privilege. People get the access their role requires. Sensitive files do not become “available to anyone who can log in.” Ask Aida, the Business Library, Smart Pages, and adaptive apps all sit behind the same identity and authorization layer.

When AI touches important work, “trust us” is not enough. Audit logging records access and activity so administrators can answer a simple diligence question: who used what, and against which documents?

If you already worry about shadow AI spend, this is the other half of that story. Centralizing the work only helps if the workspace itself is built to keep data under control.

How AI prompts are protected

A prompt is not just a question. It often contains client names, pricing, policy language, or a chunk of a confidential file. In a consumer chatbot, that text leaves your perimeter. In Aida, it stays inside an authenticated session tied to your tenant.

Protection has a few layers that matter in practice:

• Your words are treated as data, not as commands. User messages, uploaded files, form fields, web results, and retrieved library excerpts are wrapped as untrusted content. Aida is instructed not to follow hidden instructions inside those materials, not to reveal system prompts or credentials, and not to change its role because a document asked it to.
• Retrieval respects the same permissions as the library. Before Ask Aida searches internal documents, it resolves which files the signed-in user is allowed to view. The model does not get a tenant-wide dump of everything in the business. If you cannot open a file, Aida cannot answer from it on your behalf.
• Prompt context is scoped, not shared across tenants. Another company never sees your questions or your retrieved excerpts. Inside your business, the assistant only pulls what RBAC allows for that person.
• Sessions and rate limits sit in front of the model. Ask and form assistants run behind authentication (or the public-form rules you chose) and abuse controls, so the prompt path is not an open inbox to your knowledge base.

The point is not that AI is magic-proof. It is that Aida is built so a prompt cannot quietly become a back door into files the user should never see, and so everyday questions do not have to leave the company system to be useful.

How data is encrypted

Encryption is the baseline that makes the rest of the model defensible.

In transit, customer traffic uses HTTPS with TLS 1.2 or newer. The app, APIs, and integrations with providers such as Google and Microsoft travel over encrypted connections, not open HTTP.

At rest, stored data is encrypted in the managed database and in object storage used for direct file uploads. Secrets used to run the platform live in a secrets manager with keys handled by the cloud KMS, not in source code.

Some fields need more than disk-level encryption. OAuth tokens, authenticator secrets, and similar credentials are encrypted at the application layer before they are stored, so a database copy is not a pile of reusable keys.

If you keep originals in OneDrive or Google Drive and let Aida ingest them as references, the source files can stay in your cloud. Aida stores the metadata and derived search material it needs to answer questions, and it removes that derived material when the source file is deleted.

MFA for user accounts

A password by itself is a weak front door. Aida supports multi-factor authentication so a stolen password is not enough to walk into the workspace.

For password sign-in, users can enroll an authenticator app (TOTP). Privileged roles such as business administrators are required to use it. Regular users can enroll as well, and the mandate can be tightened for the whole tenant when the business wants every account behind a second factor.

Teams that sign in with Google or Microsoft can treat that identity provider as the second factor. If you use SSO, you should enforce MFA in Google or Entra for admin roles the same way you would for any other business system. Recovery codes are stored as hashes. Authenticator secrets are encrypted at rest. Resetting a password does not turn MFA off.

That is the account layer: prove who you are, then prove it again, before Aida will show you the library.

RBAC: who can see what, and who can use which features

Role-based access control is how Aida turns “this person works here” into “this person may do this job.”

Roles such as business administrator and standard user gate features: who can manage the tenant, who can publish a form, who can change access on documents. Custom admin-like roles follow the same idea. Least privilege is the default. You grant what the job needs, not a blank check.

RBAC also sits on the information itself. Document types and access rules decide whether a file is visible to the owner, to selected roles, or more broadly inside the business. Ask Aida uses that same list of viewable documents when it retrieves context. Voice agents do not search the whole library by default; they use the documents assigned to that agent.

The practical result: pricing, bid strategy, HR files, and client RFPs do not have to be equally available to everyone with a login. AI capability follows the same map as human access. That is both a security control and a way to keep features aligned with responsibility.

Without governed access	With Aida
Anyone with the shared drive link can ask AI about it	Ask Aida only retrieves files that user is allowed to view
One login level for every feature	Roles gate admin work, publishing, and sensitive tools
Forms and files inherit “open unless someone remembers”	Visibility is a setting: public, signed-in, private, or business
No trail when someone asks “who saw this?”	Audit logging of access and activity

Forms can be public or user-authenticated

Not every intake should require an Aida account. A visitor check-in, a public records request, or a job application often needs to be fillable by someone who has never signed in. An internal time-off request or an employee-only workflow should not be sitting on an open URL.

Smart Pages make that a first-class choice. Each form (and each adaptive app) has a visibility setting:

• Public — anyone with the link or embed can open and submit. Use this for candidates, visitors, customers, and citizens. Submissions still land in your tenant, behind your access rules, not in a random inbox.
• Authenticated — the person must sign in. Use this when the form should only be available to people in your business: HR requests, internal trackers, anything that assumes an employee identity.

Public does not mean unprotected. Rate limits, scoped assistants on the form, and the fact that submitted data is stored in your workspace still apply. You are choosing who may start the process. You are not choosing to dump the results on the open web.

See live examples on the Aida demos page. Some of those flows are public by design. The same product can publish a page that only signed-in users can reach.

Documents can be private to you, or limited to the business

The library is not a single shared folder with hope as the permission model. Each document has an access level.

• Private — the file belongs to the user who added it. Drafts, personal working copies, and material that should not circulate stay with that person unless they change the setting. Ask Aida will not serve that content to a coworker who cannot view the file.
• Business — the file is available inside your tenant, still subject to RBAC. This is the setting for shared policies, approved proposal language, and the knowledge the team is supposed to reuse. “Business” does not mean the internet. It means your company, with roles still able to narrow who sees sensitive types.

That distinction matters on a busy team. A proposal draft can stay private while it is unfinished. The approved capability statement can be business-wide. HR packets can remain owner-only. The assistant follows those boundaries instead of collapsing everything into one search index.

Cloud drives follow the same discipline. Aida uses least-privilege scopes to read files you choose to ingest. When a source file is removed from OneDrive or Google Drive, derived search data is deleted so the library does not keep answering from a document you already pulled back.

What this looks like day to day

1. Sign in with MFA — password plus authenticator, or your Google/Microsoft identity with MFA at the provider.
2. Land in your tenant only — no cross-company bleed of prompts or files.
3. Open what your role allows — features and documents follow RBAC, not a shared password to the drive.
4. Ask Aida from authorized knowledge — the prompt is guarded; retrieval is filtered to viewable documents.
5. Publish a form with intent — public for outside intake, authenticated for internal work.
6. Keep drafts private until they should be shared — then limit them to the business, not the world.

None of that requires a year-long governance program. It requires a default place to work, and controls that are on by design instead of bolted on after a scare.

Who this is for

Security-first Aida lands especially well when:

• Leadership will not accept RFPs, pricing, or HR files in personal chatbots
• IT needs MFA, encryption, and an access story they can explain to a customer or auditor
• Different people need different features and different documents, not one open library
• Some forms must be public (hiring, visitors, FOIA) while others must require a company login
• Individuals need a private workspace for drafts without hiding approved knowledge from the team

If you are already using Aida for document answers or content management, these controls are the reason that work can stay inside the same product.

Bottom line

AI is only useful to a business if the business still owns the data path. Aida is built that way: prompts treated as untrusted data and scoped to authorized files, encryption in transit and at rest, MFA on accounts, RBAC on features and information, forms that are public or authenticated by choice, and documents that stay private to the user or limited to the company.

Less paste-into-a-chatbot risk. More AI under your control.