Network Trust, Infrastructure, and Delivery

Enterprise problem: A correctly entitled user can still be exposed when an untrusted workload steals a token, dials an arbitrary endpoint, reads a broad secret, or deploys an unreviewed agent version, making application authorization alone insufficient.

Whole-course context: The incoming evidence is a team-scoped application deployment with independent knowledge, connector, and app-role bindings; today turns those logical grants into a constrained production path.

Today’s slice: We derive workload identity, strict mutual TLS, destination policy, secret brokerage, infrastructure ownership, and immutable canary delivery across the provider control plane and hosted runtime without granting the generated app infrastructure authority.

End-of-day evidence: A release receipt and paired connection probes prove the reviewed digest reached a canary, the runtime can call only its approved gateway with two keys, and a stolen user token or wrong workload is denied.

Still unsolved: Run-time revocation propagation, complete decision lineage, adversarial attack suites, rollback exercises, and production operations remain deferred.

Thesis: Application authorization is not a network trust boundary: a production tool call is trustworthy only when the approved immutable release, authenticated workload, and current delegated intent all meet at the gateway.

Smallest complete mental model: deliver reviewed desired state, admit a two-key connection, and attest the observed result.

Boundary: This day covers provider release state and hosted-runtime workload, network, and secret enforcement. The generated application owns its session and data authorization, while Slack, a warehouse, or another source still owns the final resource decision.

The customer outcome is a reliable, reviewable implementation of 10 network trust infrastructure and delivery. This day introduces the mechanism before policy detail and evidence review; it does not repeat the same customer stories in prose, tables, and diagrams.

Authorization policy service owns decisions; the connector/runtime gateway owns enforcement. Compute: API and isolated worker processes. Storage: PostgreSQL is authoritative for grants and state; Redis is a versioned cache; vault owns secrets; object storage retains redacted evidence only.

Implement the day’s boundary with a current, explicit decision before privileged compute or a downstream call. Bind every effect to a tenant, subject or workload, deployment, resource, and short-lived evidence ID; a cache or model response never grants authority.

Network controls can create a false sense of safety when they are treated as user authorization, and release automation can create a false sense of reproducibility when mutable names remain. The consequence is either a wide runtime blast radius or a production build that no longer matches its evidence.

A deployment manifest is only intent until a production-equivalent probe demonstrates the identity, destination, secret, and digest boundaries. Implement the HelixWorks Supplier Onboarding Agent path from release request to Slack result, then attack one key at a time.

1. Build and sign one immutable Campaign Agent artifact; pin its capability manifest, tool-schema, policy, infrastructure, and source digests in a release candidate.
2. Provision distinct SPIFFE identities for runtime, gateway, broker, and adapter; enable strict mTLS and default-deny ingress/egress before adding the exact required paths.
3. Remove connector secrets from the runtime; let only the broker or narrow adapter identity resolve the Acme Slack credential after capability-token validation.
4. Deploy the candidate to canary, compare desired and observed digest tuples, and run the allowed campaign read/post path with its normal app session and delegated authority.
5. Run negative probes for wrong workload with valid run token, valid workload without run token, wrong audience, arbitrary destination, capability replay, changed schema, and broker access before authorization.
6. Promote only the tested digest; then rehearse rollback to the prior digest while asserting the generated application's domain rows are unchanged.

Falsifiable evidence: the design fails if one-key access succeeds, the runtime can read a connector secret, arbitrary egress succeeds, a changed schema remains trusted, canary and production digests differ, rollback mutates customer data, or a release receipt cannot join source, policy, runtime attestation, and probe IDs.

Architecture diagrams cannot show whether Acme's actual runtime has an ambient credential or escape route, so inventory the Campaign Launch Agent's current identities, secret readers, egress destinations, and deployed digests. Remove the broadest path first, then capture one two-key allowed call and the paired wrong-workload, missing-token, and wrong-destination denials.

Do not expand the canary until the observed artifact, policy, schema, network, and workload revisions exactly match the reviewed tuple and rollback preserves generated-app data. A mismatch or unexpected connection is a release blocker with an owning service and immutable probe ID.

The evidence is falsifiable and observable: the release claim fails if a wrong workload or missing delegation succeeds, an unapproved destination is reachable, the served tuple differs from the reviewed tuple, or rollback damages generated-app data.

Inspect the AWS runtime identity in infra/terraform/main.tf:

resource "aws_iam_role" "task" {
  for_each = local.deployables
  name     = "helixworks-${var.environment}-${each.key}-task"
  assume_role_policy = data.aws_iam_policy_document.ecs_assume.json
}

resource "aws_ecs_task_definition" "service" {
  for_each      = local.deployables
  network_mode  = "awsvpc"
  task_role_arn = aws_iam_role.task[each.key].arn
}

Terraform declares one workload role per microservice; the AWS provider and ECS controllers interpret it; IAM roles, task definitions, and network interfaces change in cloud state; Fargate consumes CPU, memory, and network; plan output and task metadata prove the binding. IaC makes environment differences data (DRY), and each service receives an injected identity (IoC/DI). Application authorization remains separate: reachability is not business permission.

terraform -chdir=infra/terraform init -backend=false
terraform -chdir=infra/terraform validate
terraform -chdir=infra/terraform plan -var-file=environments/dev.tfvars

Inspect the plan for distinct roles and private task networking. Remove one queue permission in a disposable dev plan: only that consumer should lose access. A shared task role, public task address, or unchanged broad policy falsifies the boundary.