Connect Enterprise Systems with Workload Authority
Establish an administrator-approved machine grant before any optional user-delegated connector access.
System map · Day 08
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — People and product entry points · Generated application plane
Identity and policy
Source-backed today
Persists machine-grant metadata with explicit source, operation, tenant, expiry, and revocation boundaries.
HelixWorks control plane
Source-backed today
Owns connector approval and revocation rather than delegating enterprise authority to generated code.
Delivery and desired state
Covered — CI and immutable artifactsAhead — Git desired state · Argo CD reconciliation
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths · Kubernetes or EKS control plane
Compute and traffic
Covered — Worker compute · Generated app workloadsAhead — Ambient mesh data plane
Platform service workloads
Design target · not proved
A source adapter that exchanges and enforces the approved machine identity is still absent from the current broker implementation.
Storage and evidence
Covered — Product data and artifacts · Evidence and observabilityAhead — Infrastructure state · Cluster desired and live state
The enterprise problem and today’s slice
Enterprise problem: Generated applications often receive copied API keys with broad source access, so credentials outlive approvals and the platform cannot prove which workload read which resource.
Whole-course context: The ownership design reserves app-domain data for a future generated-app store; today adds only provider metadata representing an intended machine connector grant.
Today’s slice: Model an admin-provisioned workload grant and inspect the current connector_grants state transition; the monorepo does not yet contain a Connector Broker, source credential exchange, scoped source call, or revoke operation.
End-of-day evidence: Owner-only connector-name attachment, durable project state, non-owner denial, and connector.service_granted evidence are reproducible; workload identity, source scope, source call, and revocation remain unproved gaps.
Still unsolved: Human delegated access, private network paths, user identity mapping, sharing, and publication remain separate decisions.
Customer outcome and implementation focus
The customer outcome is a reviewable connect enterprise systems with workload authority change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
Connector Broker, workload identity issuer, and source adapter; broker pod compute; encrypted grant/secret store plus immutable audit evidence; cache: not involved because revocation must be read from authoritative state.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Issue and enforce a workload connector grant
Prove scope and revocation
Configuration inspection cannot prove a source was not called. The current model can record an owner-approved connector name, but it has no source adapter and therefore proves neither scoped source access nor revocation. Read the implemented state transition in services/control_plane/domain.py.
def grant_connector(self, project: Project, actor: str, connector: str) -> None:
self._owner(project, actor)
project.connector_grants.add(connector)
self._save_and_audit(project, actor, "connector.service_granted")
Decision rules
Provision machine authority before optional user delegation. The current connector-name set is a teaching seam, not production authority; a real workload grant still needs workload identity, resource/action scope, secret ownership, expiry, revoke, source-call denial, and an unaffected positive control.