Status: proposed enterprise baseline
Date: 2026-09-22
Program: issue #667
Scope: enterprise deployment, trust boundaries, tenancy, identity, data governance, auditability, resilience, and supply-chain controls.
IDKMesh keeps the GitHub-first G0/G1 profile as the default product experience, and adds enterprise controls as a strict overlay that can graduate to a dedicated G2/G3 control service only when tenancy, private-network, audit, state, latency, or organizational policy requires it.
Enterprise readiness is therefore not synonymous with Kubernetes, a central database, or a new login system. It means that every privileged action has a bounded authority, every tenant/data boundary is explicit, every important decision is attributable and recoverable, and operational failure has a tested safe state.
An enterprise deployment must be able to answer these questions from evidence:
A model response, a worker claim, a successful CI job, an administrator identity, or a vendor badge is not by itself an answer to these questions.
The existing G0-G4 progression remains authoritative.
GitHub repository + Actions + hosted connectors.
Best for a single project and normal asynchronous software work. No project-owned always-on service is required.
G0 plus bounded local/private workers such as a workstation, GPU node, or private-network execution node.
The node remains a worker. It is not the canonical scheduler, database, verifier, or integration authority.
Use when one organization/project needs requirements that G0/G1 cannot satisfy cleanly, such as:
G2 should normally be single-organization or dedicated tenancy.
Use only when one service deliberately manages multiple projects, repositories, or organizational tenants.
G3 adds a hard tenant boundary to every API request, state key, queue item, cache entry, audit event, secret binding, connector binding, and idempotency key.
Multiple independently operated control planes exchange bounded work/evidence. This remains future research and must not weaken the enterprise isolation requirements of G2/G3.
Human users / enterprise IdP
|
| SSO / GitHub identity / OIDC
v
+------------------------------+
| GitHub organization/repos |
| code, issues, PRs, rulesets |
| protected integration |
+---------------+--------------+
|
| webhooks / Actions / GitHub App
v
+----------------------------------------------------+
| Optional IDKMesh G2/G3 control service |
| |
| API / ingress plane |
| -> authentication |
| -> tenant context |
| -> authorization + policy decision |
| |
| coordination plane |
| -> WorkUnit admission |
| -> claims / leases / idempotency |
| -> connector routing |
| -> run state |
| |
| evidence / audit plane |
| -> append-only audit events |
| -> evidence references / digests |
| -> SIEM/archive export |
| |
| state plane |
| -> durable DB / ledger |
| -> encrypted backups |
+---------+------------------+-----------------------+
| |
| bounded dispatch | bounded dispatch
v v
hosted providers private/local workers
| |
+--------+---------+
|
v
candidate + evidence
|
v
GitHub PR/checks
|
v
protected human integration
GitHub remains the canonical code and integration authority unless a future ADR explicitly changes that boundary.
Enterprise deployments must not collapse these planes into one privileged service account.
Owns repositories, protected branches, releases, rulesets, and final integration.
A worker/provider does not receive this authority merely because it can create a candidate branch or pull request.
Owns admission, routing, claims, run state, retry/idempotency, policy evaluation, and operator status.
The control plane may decide that work is eligible to execute. It does not decide that the resulting candidate is correct or merged.
Runs untrusted or semi-trusted work in hosted providers, CI sandboxes, local nodes, private runners, containers, VMs, or other substrates.
Execution identity is provenance, not repository authority.
Records verification evidence and privileged control events.
Evidence can recommend or document a decision. The audit stream records what happened. Neither one is permission to integrate.
For G3 and any deployment claiming shared tenancy:
Issue #669 owns executable isolation work.
The normalized identity model should distinguish at least:
Enterprise authorization is stage-specific.
actor + tenant + action + resource + risk + data class + policy revision
|
v
allow / deny / approval required
High-risk operations should support separation of duties. A single person may hold multiple organizational roles, but enterprise policy can require distinct actors for a particular execution/integration path.
Break-glass access must be explicit, time bounded, reason required, and audited. It must not silently become the normal operating path.
Issue #670 owns the identity/RBAC/ABAC/SoD implementation.
The enterprise baseline uses four minimum data classes:
A WorkUnit or project policy can tighten classification. An agent/model cannot lower it.
External processing is a non-compensating eligibility check. If policy forbids a data class from leaving the approved trust boundary, model quality, cost, speed, or administrator convenience cannot override that rule.
Enterprise workers should support:
Issue #672 owns the data/egress/secrets boundary.
Tracked configuration stores references, never credential values.
Preferred order for enterprise/cloud access:
Authorization happens before secret materialization.
Secret access should be auditable as a decision and resource reference without recording the secret value.
Ordinary application logs are not the enterprise audit ledger.
A privileged audit event should bind:
The baseline requires append-only semantics. G2/G3 production deployments should support export to an organization-controlled archive/SIEM.
Audit evidence records decisions; it does not grant authority by existing.
Issue #671 owns the audit ledger/export contract.
Enterprise operation requires explicit objectives rather than adjectives such as “high availability.”
The Enterprise Control Profile records:
These are declared objectives until measured by a pilot.
Required failure behavior:
Issue #673 owns operational SLO/DR work.
Enterprise release controls should progressively provide:
GitHub artifact attestations and OIDC can support these controls, but an attestation proves provenance/integrity facts, not functional correctness.
Issue #674 owns release/supply-chain hardening.
Operational telemetry and audit evidence are separate.
Metrics/logs/traces should support:
Telemetry must avoid secret values and should minimize sensitive task content.
Enterprise operation needs an accountable control loop:
proposed change
-> reviewed policy/config/code
-> exact revision
-> staged validation
-> deployment
-> observed health
-> rollback or acceptance
Security incidents should have stable incident identifiers that can be referenced by audit events, emergency changes, and post-incident evidence.
Emergency access must leave more evidence than normal access, not less.
The optional service tracked by #675 should be introduced only after the repository-only pilot identifies a need or an enterprise control explicitly requires it.
Minimum service qualities:
A database, queue, container orchestrator, or cloud vendor is an implementation choice beneath these invariants.
IDKMesh may map controls to common enterprise frameworks in future, but the project MUST distinguish:
A passing IDKMesh enterprise preflight is not a SOC 2, ISO 27001, FedRAMP, HIPAA, PCI DSS, or similar certification claim.
Issue #676 owns destructive conformance testing.
Implemented on main today:
Planned/open enterprise work:
Do not describe the planned controls as production-enforced until their issues and acceptance evidence are complete.
The baseline is ready for an enterprise pilot only when the system can demonstrate that:
That evidence, rather than infrastructure size, is what makes the system enterprise-operable.