Identity and security
Governance and ownership
Roles, risk classes, capability floors, approval authority, and organization-owned app lifecycles.
v1 design baseline. This page specifies intended behavior. Delivery and validation are tracked in the implementation plan; it is not a claim that the platform is already implemented.
Organization roles
| Role | Typical authority |
|---|---|
| Viewer | View permitted apps and deployments. |
| Creator | Create apps, edit managed source, build, preview, request deployment. |
| Developer | Git/API access, advanced diagnostics, source ownership, technical maintenance. |
| Deployer | Deploy within delegated risk/capability limits. |
| Approver | Approve designated deployment classes. |
| Security Admin | Identity, IP lists, policies, secrets, integrations, capability approval. |
| Org Admin | Organization-wide administration and role assignment. |
Permissions should remain granular even if the UI initially presents role bundles.
Risk classes
Sandbox
- Synthetic data
- Creator/reviewer access only
- No production integrations
- No secrets
- Short retention
- Self-service preview
Standard internal
- Entra SSO
- Normal internal workflow data
- SQLite and KV
- Controlled egress
- Organization/group access
- No regulated data
Sensitive
- Privileged internal data
- Secrets or external integrations
- Broad departmental use
- Expanded access policy
- Stronger approvals and logging
Regulated
- Regulated data
- Integrations subject to compliance requirements
- Contractual/compliance controls
- Approved AI configuration
- Dedicated policy and retention
- Formal review
The v1 organization pilot enables only Sandbox and Standard Internal.
Capability-driven minimum risk
The creator does not get to misclassify an app as low risk.
Examples:
Requests only DB + KV + Entra SSO
→ Standard may be sufficient
Requests generic raw secret
→ at least Sensitive
Requests private-network connector
→ at least Sensitive
Requests regulated-data capability
→ Regulated
Requests public exposure
→ security approval and organization permission
An administrator may raise the risk class but may not lower it beneath the computed capability floor.
Approval matrix
Pilot policy:
| Change | Approval |
|---|---|
| Sandbox preview | Creator |
| Standard internal production deployment | Authorized human approver |
| Destructive migration | Authorized approver |
| New external integration | Security Admin |
| Access expansion | Security Admin |
| Public exposure | Disabled |
| Private network | Disabled |
| Regulated-data capability | Disabled |
| Organization policy | Security Admin/Org Admin |
| AI self-approval | Never |
Application ownership
Every production app has:
Organization owner
Business owner
Technical owner/maintainer
Risk class
Data classification
Last review date
Next review date
When the creator leaves:
- App remains organization-owned.
- Direct credentials are revoked.
- Business/technical ownership is reassigned or flagged.
- Production is not automatically deleted.
- Administrators receive an orphaned-app alert.
Lifecycle
Draft
Preview
Production
Suspended
Archived
Pending Deletion
Purged
Inactivity policy examples:
No production traffic for 180 days
→ flag for review
No production traffic for 365 days
→ archive candidate
Deletion initially disables routes and starts a recovery window. Permanent purge follows organization retention policy.
Governance dashboard
Organization administrators should see:
Production apps by risk class
Apps with external egress
Apps with integrations
Apps with destructive migrations pending
Apps missing owners
Apps overdue for review
Apps with broad network access
Apps with policy exceptions
AI-created changes awaiting review
Backup/restore health
Quota consumption