Trust center
AI can write software. The harder question is whether you can approve it.
ObjectOS is designed for the procurement, security, and IT review that happens after a demo works. It keeps business data under customer control and makes agent authority explicit in metadata and runtime enforcement.
- Self-hosted
- Run in your VPC, servers, or isolated network
- User scoped
- Agents inherit the signed-in user permissions
- Auditable
- Reads, writes, tool calls, approvals, and schema changes
Security review packet
What a reviewer should receive before sign-off
A governed AI app should arrive with an architecture boundary, object authority map, approval policy, audit plan, integration list, model routing, and rollback plan. ObjectStack metadata is structured so those materials can be generated from the same source definitions.
- Deployment boundary: where runtime, database, files, identity, and models run.
- Authority map: object, record, field, workflow, action, and AI tool permissions.
- Audit plan: what is logged for people, agents, APIs, and approvals.
- Change plan: how metadata changes are reviewed, promoted, and rolled back.
Boundaries
Keep sensitive business data inside controlled infrastructure
ObjectOS can run as a self-hosted runtime. Unless you configure external providers, business records, prompts, files, audit logs, and credentials stay in infrastructure you control.
Data residency
Connect customer-controlled databases and storage. ObjectOS does not require application records to be copied into a vendor workspace.
No required telemetry
The open-source runtime does not need a license callback or product telemetry channel to operate.
Model choice
Use cloud models, private endpoints, or local models based on the sensitivity of the workflow and deployment.
Authority
AI acts through governed tools, not raw database access
The runtime evaluates identity, roles, row rules, field rules, approval policy, and action contracts before an AI tool can read or write data.
Signed-in user inheritance
AI sees what the user can see and acts only within the user authority unless an explicitly approved service role is configured.
Approval before sensitive writes
High-risk actions such as refunds, contract changes, escalations, exports, and permission updates can require human approval.
Field-level controls
Sensitive fields can be hidden, read-only, masked, or excluded from AI tool exposure even when the record itself is visible.
Decision surface
What changes, who reviews it, what runs
| Review area | Available now | Enterprise packet |
|---|---|---|
| Deployment | Self-hosted open-source runtime | VPC, private network, air-gapped deployment notes |
| Identity | Project identity and permission metadata | SSO, SCIM, admin roles, session policy mapping |
| AI governance | MCP tools, object permissions, approvals | Model routing policy and prompt/data boundary report |
| Audit | Runtime audit design and metadata review | Exportable audit retention and investigation workflow |
Review checklist
Security review checklist
- Where does each class of business data live?
- Which model endpoints can receive prompts or retrieved records?
- Which objects, fields, and actions are exposed to AI tools?
- Which writes require human approval?
- How are user actions and agent actions distinguished in audit?
- How is a bad metadata change rolled back?
FAQ
Questions this page should answer
Does ObjectOS train models on customer data?
Self-hosted deployments are controlled by the customer. Cloud or Enterprise data usage should be governed by the relevant commercial agreement; the product direction is to keep customer data out of general model training unless a customer explicitly agrees.
Can ObjectOS run without internet access?
The runtime is designed for self-hosted and isolated deployment patterns. The exact operating model depends on package mirrors, model routing, identity, and customer infrastructure.
Next pages