Team and Organization Access
OneAI already has organization membership and role foundations. This page turns that structure into a customer-facing enterprise access model without changing existing APIs.
Organization
-
Your role
-
Plan
-
Active keys
0
Live Members
Members loaded from the current organization membership table.
Owner-only action. The member is attached to this organization and all changes are audit logged.
| Member | Role | Joined | Actions |
|---|---|---|---|
| No members loaded. | |||
Live Access State
Current organization permissions and usage footprint.
Owner
Owns the organization, billing relationship, plan policy, and final approval for production access.
Admin
Operates customer-facing infrastructure with high-trust access to keys, usage, and support workflows.
Member
Builds and tests against approved tasks, models, and API keys without changing organization policy.
Viewer
Reads dashboards, invoices, execution records, and audit trails without changing production state.
Permission Matrix
Default enterprise permissions for customer organizations.
| Capability | Allowed roles |
|---|---|
| Create API keys | Owner / Admin |
| Set budgets, RPM, IP allowlists | Owner / Admin |
| Change billing plan | Owner |
| View invoices | Owner / Admin / Viewer |
| View usage and costs | Owner / Admin / Member / Viewer |
| Run commercial tasks | Owner / Admin / Member |
| Review Agent OS proof | Owner / Admin |
| Change member roles | Owner |
Enterprise Rollout State
What is already true, and what should remain explicit.
Organization, membership, and role data already exist in the backend.
Current console access is protected by Google/console login and operator checks.
Next enterprise step is self-serve invite, remove, and role-change workflows.
Role changes, key changes, billing changes, and failed requests should remain audit logged.
Commercial Boundary
Team permissions govern access to OneAI intelligence infrastructure. Execution stays outside OneAI.
Per-key policy can control budgets, RPM, IPs, task allowlists, and model allowlists.
Login, key, billing, request, failure, and Agent OS events are designed to be traceable.
SLA, DPA, invoices, terms, and privacy documents are linked from Docs, Security, and Billing.