[Enterprise Gap] Deliver the operator console, identity, tenancy, audit, and SLO control plane

[seonghobae]

Buyer-visible gap

OriginWeave currently defines a governed browser runtime and strong Rust authority primitives, but an enterprise buyer cannot yet administer tenants, identities, managed policies, approvals, sensitive-data access, browser sessions, evidence, incidents, retention, or service objectives through a coherent product surface.

A production enterprise product needs more than safe kernel types. It needs an operator experience that answers:

• Who or which workload may delegate this task?
• Which origins, actions, models, extensions, connectors, and protected fields are permitted?
• Which approval is waiting, why is it required, and what exact side effect will occur?
• What happened, which evidence supports it, and which control was applied?
• Is the service healthy, within SLO, recoverable, and operating in the contracted region?

This issue owns the enterprise control and experience plane. It composes #10, #27, #28, #199, #200, and #201; it does not replace their runtime/security implementation.

Product surfaces

Deliver the following accessible applications, backed by versioned APIs rather than UI-local authority:

Enterprise Admin Console
Task and Approval Workspace
Evidence and Replay Explorer
Policy and Destination Workspace
Sensitive Data and Secret Access Workspace
Extension and Native Host Workspace
Operations and Incident Console
Customer Audit / Procurement Portal

The user-facing language for every warning, denial, approval, recovery action, and evidence gap must state the next valid action rather than merely reporting an internal state.

Identity and tenancy

Integrate with Keyverse-compatible OIDC/OAuth and SCIM without copying authentication credentials into OriginWeave.

Required identity classes:

human_identity
workload_identity
service_identity
device_identity
agent_identity
support_identity

Required controls:

• issuer, audience, nonce, token lifetime, and signature verification;
• tenant and organization membership;
• role and attribute policy;
• workload/service identity for machine calls;
• device/session risk where configured;
• just-in-time provisioning and SCIM deprovisioning;
• explicit support access, disabled by default;
• maker-checker administration for high-risk policy, keys, export, refund/credit-like adjustments if billing integration is later enabled, and break-glass access;
• no email-address-only account merging;
• no cross-tenant access through administrator, support, cache, queue, object store, search, vector, audit, or model boundaries.

OriginWeave person/workload references remain opaque links. Keyverse owns authentication and credential lifecycle; OriginWeave owns browser-task authorization and evidence.

Authorization and managed policy

Provide versioned, effective-dated policy administration for:

• session mode and task purpose;
• allowed origins and redirect policy;
• destination classes, proxies, PAC sources, VPN profiles, and connectors;
• typed Agent actions and risk classes;
• model/provider/region/retention/training/subprocessor rules;
• protected-data field and business-purpose disclosure;
• secret broker use;
• extension/native-host admission and Agent grants;
• resource budgets;
• capture, export, retention, legal hold, and deletion;
• human approval and dual control;
• browser/distribution release channels; and
• emergency disablement.

Policy changes must produce immutable revisions, impact previews, explicit activation windows, rollback/supersession, and complete decision evidence. Draft policy or LLM recommendation never becomes active without the configured authority.

Approval workspace

An approval must preview the exact immutable intent:

• actor, workload, task, tenant, purpose;
• current origin and destination;
• action kind and side effect;
• fields/secrets disclosed and destination class;
• model/provider/region when applicable;
• files uploaded/downloaded;
• expected post-condition;
• resource/cost exposure;
• expiry and maximum use count; and
• evidence that will be captured.

Required states:

approval_requested
→ approved | denied | expired | withdrawn
→ consumed | revoked

• R3/R4 actions require the configured human or dual-control approval.
• R5 legal consent remains non-delegable.
• Approval is bound to the complete action-intent digest and cannot be reused after origin, fields, file, amount, destination, model, policy, or document epoch changes.
• Accessibility, keyboard, screen-reader, high-contrast, reduced-motion, mobile, print, and exact-value views are release requirements.

Evidence and audit experience

Provide an Evidence Explorer that keeps fact classes distinct:

trusted instruction
policy decision
browser/network observation
model inference
human approval
action dispatch
post-condition verification
capture artifact
operator annotation

Users must be able to:

• trace a result or action to exact evidence and software/policy versions;
• compare planned versus observed destination, peer, TLS, HTTP, node, action, and result;
• inspect completeness, redaction, retention, and integrity state;
• export policy-filtered audit packages;
• replay supported captures through [Product Gap] Deliver schema-bound extraction with durable WARC/PROV replay #199;
• see missing or stale evidence without it being rendered as success;
• create incident/correction annotations without rewriting immutable records; and
• verify hash chaining or equivalent tamper-evident sequencing.

Raw protected values are not inserted into generic audit, analytics, browser-accessibility labels, screenshots, support bundles, or model history. Authorized reveal/copy/export is a separate policy decision.

Operations and SLOs

Define production SLI/SLO profiles for standalone and enterprise deployment.

Minimum SLIs:

task_admission_availability
browser_session_start_success
governed_action_success
policy_decision_latency
approval_delivery_latency
artifact_persistence_success
provenance_completeness
queue_depth_and_age
cancellation_latency
crash_recovery_success
profile_cleanup_success
update_success
security_event_delivery
backup_restore_success

The console must expose:

• current and historical SLO attainment;
• per-tenant capacity and quotas;
• queue saturation/backpressure;
• browser/renderer/GPU/process health;
• adapter/provider degradation;
• release and updater state;
• incident timeline;
• dead-letter and reconciliation queues;
• backup/restore and disaster-recovery evidence;
• regional storage/processing state; and
• next remediation action.

Do not put tenant IDs, personal data, prompt/response text, secrets, URLs with credentials, or high-cardinality protected values in metric labels.

Deployment and data residency

Support modular deployment profiles:

single-node evaluation
enterprise compose
kubernetes / private cloud
regional SaaS
customer-managed evidence storage
restricted or air-gapped deployment

• Product services remain independently replaceable through versioned contracts; do not create a UI-driven distributed monolith.
• Tenant and region policy must be executable at database, object store, cache, queue, search, model, support, backup, and export boundaries.
• Encrypt data in transit and at rest with versioned key references; support customer-managed keys where contracted.
• Provide backup, restore, failover, key rotation, deletion, and regional migration runbooks with rehearsal evidence.
• PII remains usable by authorized business workflows through [Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking #10; blanket masking is not the architecture. Ambient propagation is prohibited.

Data model

Every database object must contain at least two words and use snake_case. Suggested objects:

tenant_account
tenant_membership
identity_reference
workload_identity
service_identity
role_definition
role_assignment
policy_definition
policy_revision
policy_activation
policy_impact_record
approval_request
approval_decision
support_access_request
break_glass_event
audit_event
audit_sequence_record
incident_record
incident_timeline_event
slo_definition
slo_observation
capacity_policy
regional_policy
retention_policy_record
backup_rehearsal
restore_rehearsal
control_evidence_mapping

Use 3NF for identity links, policy revisions, assignments, approvals, SLOs, controls, and lifecycle. JSON may preserve immutable external payloads but must not hide authorization or tenant enforcement.

Figma, design tokens, and Storybook

Before production UI implementation:

1. create the OriginWeave Figma file and record the exact Figma File ID in an accepted UI architecture ADR;
2. define reusable design tokens for typography, spacing, state, risk, evidence, focus, motion, and data visualization;
3. build a Storybook inventory for every repeated component and state; and
4. test implementation parity against approved Figma frames.

Required component inventory includes:

TaskCard
ApprovalIntent
RiskBadge
OriginGrant
DestinationEvidence
TlsIdentityEvidence
SensitiveFieldDisclosure
ExtensionGrant
PolicyDiff
EvidenceTimeline
ProvenanceGraph
SloCard
IncidentTimeline
AuditExport

Required states include loading, empty, partial evidence, stale evidence, access denied, approval required, conflict, policy changed, provider degraded, replay unavailable, incident, and recovery. Every graph/chart must have an exact-value table and export/print representation.

Accessibility and usability acceptance

• WCAG 2.2 AA conformance target for all supported operator/customer surfaces.
• Keyboard-only completion of task review, approval, denial, evidence inspection, policy comparison, export, and incident response.
• Screen-reader announcements must not expose protected values through hidden DOM or accessible labels.
• High-risk actions require clear confirmation while preserving efficient reviewed workflows.
• UI text explains consequences, expiry, missing evidence, and the next valid action.
• Figma and Storybook tests cover responsive, localization, error, empty, loading, policy conflict, and offline/degraded states.

Security, CSAP, and SOC 2 evidence

Create versioned control_evidence_mapping records rather than certification claims.

• Map the actual deployed service boundary, assets, identities, encryption, tenant isolation, access control, audit, incident response, change/release management, continuity, data location, and supply chain to current applicable CSAP criteria.
• Map product capability, configured control, operating control, collected evidence, management assertion, and independent examination result separately for SOC 2 Trust Services Criteria.
• Provide evidence owners, collection cadence, retention, exceptions, and assessor-facing exports.
• No UI, README, release note, or sales document may claim CSAP certification or SOC 2 compliance without the valid certification/report for the defined system and period.

Realistic tests

1. Two tenants with identical external usernames cannot see, infer, approve, search, export, or support-access each other's task/evidence data.
2. SCIM deprovisioning removes future access without rewriting historical audit attribution.
3. Policy draft/review/activation/rollback behaves bitemporally and produces deterministic impact/evidence.
4. Maker-checker prevents self-approval for configured high-risk changes.
5. Approval intent mutation, stale document epoch, expired approval, wrong origin, wrong field, wrong file, wrong model, and replay fail closed.
6. An authorized operational-PII task succeeds through [Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking #10 while all unauthorized logs, traces, screenshots, exports, support bundles, and models remain value-free.
7. Backup/restore, regional failover, key rotation, deletion, legal hold, and disaster recovery are rehearsed against realistic tenant data.
8. Queue saturation, provider outage, browser crash, updater failure, and database/object-store degradation produce truthful SLO and incident states.
9. Keyboard and assistive-technology journeys complete approval, policy, evidence, export, and incident workflows.
10. Storybook interaction/visual/accessibility tests and Figma parity checks pass for every declared component/state.
11. Tenant policy, approval, audit, and operations production function/line/region/branch coverage is exactly 100%; public APIs are fully documented; no required E2E/security/accessibility test is skipped.

Use synthetic or explicitly approved anonymized fixtures. Production identities, institutions, or customer data must not enter source, tests, ADRs, screenshots, or demos.

Dependencies and non-goals

Dependencies:

• [Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking #10 protected-data broker/runtime;
• [Product Gap] Prove Manifest V3 extension compatibility and isolate extension authority #27 extension compatibility and isolation;
• [Product Gap] Complete the first real Chromium agent vertical slice #28 real Chromium execution;
• [Product Gap] Deliver schema-bound extraction with durable WARC/PROV replay #199 durable evidence/replay;
• [Product Gap] Publish a stable BAP/MCP runtime API with resumable task lifecycle #200 stable runtime API/task lifecycle;
• [Product Gap] Ship a signed cross-platform Chromium distribution and update lifecycle #201 signed distribution and update lifecycle.

Non-goals:

• building a second identity provider instead of Keyverse integration;
• giving UI code direct database, browser, secret, or policy authority;
• treating documentation presence as an operating control;
• blanket PII masking that prevents authorized work;
• claiming certification from unit tests alone;
• making inferred/model-generated findings authoritative without review.

Commercial proof

A regulated enterprise administrator can provision identities, define and review policy, approve an exact high-risk action, operate the runtime against SLOs, investigate and replay evidence, export a control package, and recover from an incident—while a second tenant and unauthorized support user remain unable to access the data or authority.

Standards and authoritative references — APA 7th

World Wide Web Consortium. (2024). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Chandramouli, R., & Butcher, Z. (2023). A zero trust architecture model for access control in cloud-native applications in multi-cloud environments (NIST Special Publication 800-207A). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207A

American Institute of Certified Public Accountants. (2023). 2017 trust services criteria for security, availability, processing integrity, confidentiality, and privacy (with revised points of focus—2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022

Korea Internet & Security Agency. (n.d.). 클라우드서비스 보안인증제 제도소개. https://isms.kisa.or.kr/main/csap/intro/index.jsp

[seonghobae]

Enterprise approval boundary follow-up from current PR #220 review: exact (issuer, subject) inequality is only a local tuple-separation check and does not prove distinct real actors when one human/workload can hold aliases or multiple federated identities. PR #220 now documents this explicitly at exact head 4d274939f5601d372976d59e6983104ed44a3940; the policy crate intentionally does not authenticate or correlate principals. The #202 identity/workflow control plane must therefore canonicalize/authenticate actor identity (or an equivalently reviewed stable actor key) and fail closed when maker and checker resolve to the same real actor, including linked accounts/aliases/federated identities, before invoking approve/deny. Preserve tenant membership, checker-role, exact-scope authorization, and audit evidence separately; do not solve this by weakening tuple checks or by email-only identity merging.