Security and governance

Give AI agents governed access to real business data.

ObjectOS comes in three editions, ObjectOS Community, Cloud and Enterprise. It lets agents read, analyze, and move work forward inside explicit boundaries for identity, permissions, tools, approvals, and audit. On ObjectOS Enterprise, data stays on your infrastructure; on every edition, every AI action is constrained by the ObjectStack runtime.

Agent
inherits user identity
Tool
governed access path
Audit
approval and evidence

How agents act

AI agent safety model

ObjectOS does not treat the model as an administrator. Agents work through business objects and use declarative tools to query, analyze, or trigger actions. Tool input is validated, every call is checked against the same permission system, and the in-product AI changes a record only after the user confirms it.

  1. 01

    Acts as a user

    An agent represents a signed-in user, not an unrestricted service account. If the user cannot see a record, the agent cannot see it either.

  2. 02

    Uses governed tools

    Agents call structured query, action, and metadata tools instead of holding raw database credentials or dumping whole tables into prompts.

  3. 03

    Waits for a person

    The in-product AI proposes a record change with the old and new values, and runs it as the user only after that user confirms. On ObjectOS Cloud, an AI Builder change to a live app that already holds records is saved as a draft for a person to publish.

  4. 04

    Leaves evidence

    Record reads and writes, approvals, rejections, and permission changes are written to the audit log. Per-call audit of the in-app AI’s tool calls is part of AI governance on Enterprise.

Where data lives

Data residency

ObjectOS Enterprise does not require moving business data into our cloud: the ObjectStack runtime connects to your databases, storage, and identity systems, so residency follows your deployment boundary.

DataLocationLeaves boundary?
Business records Your database No
Users, sessions, OAuth tokens Your database No
Audit logs Your database No
Uploaded files Local disk, S3, or R2 No
Secrets and settings Your secret manager or encrypted settings store No
AI request context Your chosen model provider or local model Only if you configure an external model

Who may do what

Permissions and audit

The access model uses enterprise software vocabulary: identity, roles, permission sets, record access, and field security. Simple apps can start with permission sets; regulated, CRM, or multi-tenant apps can add finer boundaries later.

Identity

Users, organizations, memberships, sessions, and API keys live in your project database.

Permission sets

Grant app access, object CRUD, field read/write, system capabilities, and integration capabilities.

Record access

Ownership, organization scope, sharing rules, and explicit shares decide which rows a user can touch.

Field security

Sensitive fields can be hidden or read-only even when the record is visible, consistently across API, ObjectQL, and Console.

Audit logs

Record CRUD, permission grants, session revocation, and approval decisions, plus the in-app AI’s tool calls on Enterprise; audit rows are immutable and can only be archived.

Go deeper

The two pages behind this one

This page is the entry point for a security review. Two pages go further: the trust center collects the review materials, and the permissions page shows the access model as metadata a reviewer can read.

Where it runs

Deployment boundary

ObjectOS Enterprise can operate ObjectStack inside your network: one Node.js runtime, your database, your secrets, and your ingress. Stricter environments can use file-backed artifacts and offline images.

VPC / private network

Run in your cloud account or private network with only required HTTP/HTTPS and database connectivity.

Local servers

Run with Docker, systemd, or your own platform while connecting local databases, object storage, and identity.

Air-gapped

Use offline container images and a local objectstack.json artifact with no cloud control plane or public internet requirement.

Local models

Point AI services at Ollama, vLLM, or internal model endpoints to keep business context inside your boundary.

FAQ

Security review FAQ

Does ObjectOS phone home?

Self-managed ObjectOS validates its license online; Enterprise air-gapped licenses validate offline. Beyond that, unless you explicitly configure integrations such as OIDC, email, AI providers, webhooks, or external storage, no business data leaves your deployment. The open-source ObjectStack runtime has no telemetry, no license check, and no update ping.

What goes to a model provider?

Only the context required for the model task: conversation context, tool definitions, and necessary tool output. You can use an external model or configure a local model endpoint.

How do we limit agent writes?

Use read-only data sources, object permissions, field permissions, action permissions, and flow approval steps for business decisions. Agents cannot bypass runtime permissions. The in-product AI changes one record at a time after the user confirms it, and cannot delete records or edit them in bulk; on ObjectOS Cloud, an AI Builder change to a live app that already holds records is saved as a draft for a person to publish.

Who owns TLS, database encryption, and secrets?

Those are deployment responsibilities. The ObjectStack runtime provides authorization, audit, API key hashing, and settings encryption; your infrastructure owns TLS, at-rest database encryption, backups, and secret injection.

Is it suitable for regulated environments?

ObjectOS provides the technical primitives: access control, audit, data residency, and isolated deployment. Certification depends on your running deployment, not a binary alone.

Found a vulnerability?

Vulnerability disclosure

Report security problems in ObjectOS Cloud, ObjectOS Enterprise, the open-source ObjectStack runtime and packages, or this website privately by e-mail. Please do not open a public GitHub issue, discussion, or pull request for a security problem.

Acknowledgement
Within one business day
Languages
English or Chinese

What to include

  • The product and version affected: for Cloud, the date and time you tested; for a self-managed deployment, the image or package version.
  • Steps to reproduce, with a proof of concept if you have one.
  • The impact you observed: what an attacker could read, change, or run.
  • Whether you have shared the finding with anyone else, and when you plan to publish it.
  • How to reach you, and the name you want credited, if any.

What happens next

  1. We acknowledge your report within one business day.
  2. We confirm or rule out the issue and keep you updated while we fix it.
  3. Once a fix is available, we agree a public disclosure date with you and credit you if you want.

Safe harbour

We consider good-faith security research under this policy authorized, and we will not bring or support legal action against you for it. Good faith means you:

  • Test only accounts and environments you own or have permission to use, and stop as soon as you reach data that is not yours.
  • Do not view, keep, change, or delete other people’s data beyond the minimum needed to show the issue.
  • Do not run denial-of-service, spam, social-engineering, or physical attacks.
  • Give us reasonable time to fix the issue before you disclose it publicly.

Next step

Let agents work with business data without crossing the boundary.

Confirm how agents identify users, access objects, trigger actions, enter approval, and leave audit evidence before connecting them to production data.