Security and governance

Give AI agents governed access
to real business data.

ObjectOS does not keep AI outside the business. It lets agents read, analyze, and move work forward inside explicit boundaries for identity, permissions, tools, approvals, and audit. Data stays on your infrastructure, and every AI action is constrained by the runtime.

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

AI agent safety model

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, mutating work goes through approval, and every call is checked against the same permission system.

  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

    Queues changes

    Tools that modify metadata or sensitive state enter a pending-action queue so reviewers can inspect the diff before applying it.

  4. 04

    Leaves evidence

    Conversations, tool calls, reads, writes, approvals, rejections, and permission changes can be written to audit logs.

Data residency

Data residency

ObjectOS does not require moving business data into our cloud. The 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

Permissions and audit

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, AI tool calls, and approval decisions; audit rows are immutable and can only be archived.

Deployment boundary

Deployment boundary

The default shape is enterprise-network friendly: 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.

Security review FAQ

Security review FAQ

Does ObjectOS send telemetry?

No. Unless you explicitly configure integrations such as OIDC, email, AI providers, webhooks, or external storage, ObjectOS does not send telemetry, contact a license server, or transmit data back to ObjectStack.

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 approval queues. Agents cannot bypass runtime permissions or silently apply structural changes.

Who owns TLS, database encryption, and secrets?

Those are deployment responsibilities. ObjectOS provides runtime 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.

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.