LOCO Enterprise Double-Silo Pattern · The EOSE

WHAT IS THE DOUBLE-SILO PATTERN?

TRB-LOCO-CTC-ENTERPRISE-DOUBLE-SILO-001

DOUBLE-SILO TOPOLOGY · EOSE operates INSIDE CTC's Azure tenant + EOSE's own AKS simultaneously

SILO A — CTC AZURE (managed-dev-001-test-cc-aks)

✅ Istio ASM — CTC-managed control plane

✅ OPA Gatekeeper — policy enforcement

✅ Flux GitOps — ADO → cantire.com registry → Helm

✅ AKV + Venafi + cert-manager

✅ Azure Monitor + New Relic + Sentinel

✅ PIM + Workload Identity OIDC

GPU: A10 36GB (×2) + H100 (×1) spot nodes

⚠️ 30yr k8s internal certs (non-compliant)

EOSE services in eose-entry namespace

⇌

SILO B — EOSE AKS (aks-eose-aaas-dev, canadacentral)

✅ Istio ASM 1.28 · 52 Envoy sidecars

✅ mTLS STRICT · 17 namespaces

✅ KMS V11 · EOSE-managed secrets

✅ cert-manager · VS TLS managed

✅ Flux GitOps in pemos-system

⚠️ No image signing on eosefleetacrdev

⚠️ No ResourceQuota on ct-fac-system

⚠️ No Workload Identity on ct-fac-system

⚠️ No Sentinel rules for ct-fac-system

SHARED LAYER — Services operating across both silos simultaneously

ct-builder-gateway · EOSE entry gate

ct-fac-portal · UI/API layer

merostone-relay · public ingress bridge

campfire-redis · event bus

tfe-agent · IaC in both silos

ct-intel-pusher · 15min CronJob ⚠️ NEEDS CLARITY

mdsms-router · cross-silo signal

eose-operator · CRD lifecycle

DOUBLE-LOCO SCORECARD

D1–D11 · CTC Silo A vs EOSE Silo B · honest, no softening

D1

Secret Mgmt

AKV-backed everywhere, CSFLE on MongoDB, no hardcoded creds

10/10

9/10

EOSE KMS live; ct-fac uses redis (no AKV direct). Add AKV SecretStore for ct-fac.

D2

Network Isolation

Private Link on all AI endpoints, NSG, private AKS cluster

10/10

9/10

mTLS STRICT in ct-fac-system but no PeerAuthentication policy set. Add PeerAuth STRICT.

D3

Image Governance

artifacts.cantire.com + aksrepo001, no DockerHub, full chain

10/10

7/10

eosefleetacrdev.azurecr.io present but no image signing enforced. Cosign + OPA policy needed.

D4

Gateway Auth

Okta + APIM + SPN per env, full auth chain

10/10

9/10

Istio gateway + VirtualService present; no APIM equivalent. AuthorizationPolicy for ct-fac recommended.

D5

Data Encryption

TLS 1.2+, restrictOutbound, CSFLE at rest

10/10

9/10

TLS in mesh; ct-fac-redis not encrypted at rest (known). Redis TLS + persistence encryption.

D6

Compute Limits

Resource quotas + LMZ namespace policy enforced

10/10

6/10

ct-fac-system has NO ResourceQuota or LimitRange. P0 before any CTC security audit.

D7

Logging

Azure Monitor + New Relic + Sentinel alerting live

10/10

7/10

Azure Monitor on cluster; no ct-fac-specific Sentinel rules. Add alert rules for ct-fac anomalies.

D8

Cert / TLS

Venafi + cert-manager; 30yr k8s certs flagged

8/10

9/10

EOSE actually scores higher here. cert-manager live, VS TLS via Istio, no long-lived certs.

D9

GitOps

Flux v2 all clusters, ADO → internal registry → Helm

10/10

9/10

Flux on EOSE AKS; ct-fac deployments still manual. Add Flux Kustomization for ct-fac-system.

D10

Identity

PIM + Workload Identity OIDC + federated creds

10/10

7/10

WI on pemos-system; ct-fac-system WI not configured. Add ServiceAccount + WI annotation per service.

D11

Agent Identity

No framework for AI agent PKI, human sponsors, kill-switches in enterprise AI

6/10

3/10

P0 CRITICAL. Nobody has D11 right in 2026. EOSE has 12-month window to own this domain. DCJ-037 + ARB1-LOCO-ENGINE-001.

⚡ D11 — AGENT IDENTITY: THE DOMAIN NOBODY HAS RIGHT

What D11 requires: Every AI agent operating in an enterprise system must have a cryptographically verifiable identity, a named human sponsor, a documented scope of authority, and a kill-switch that works within 60 seconds. When an agent acts, there must be an audit trail that shows: which agent, which model version, which human authorised it, what scope it had, and what it did.

CTC's gap (6/10): ChatCTC has no agent identity framework. The kb-reader and embedder services have no PKI, no sponsor mapping, no kill-switch. If an agent misbehaves in a Microsoft Copilot deployment inside CTC's tenant, there is no systematic way to attribute, isolate, or reverse the action. Wael's SecArch V5.4 section 3.2 requires this — but the implementation is not there yet.

EOSE's gap (3/10): More serious. openclaw agents are operating in CTC's Azure tenant (eose-entry namespace) with cluster-admin. There is no EOSE agent identity framework documenting which agent is which, what scope it has, who the human sponsor is, or how to kill it. This is acceptable for Day 83 of a startup. It is not acceptable at Day 180 when CTC security reviews the engagement.

The 12-month window: In 2026, no enterprise has D11 implemented. Microsoft, Google, and AWS all have the same gap. The first vendor to ship a production-ready Agent Identity Framework (AIF) with PKI-backed agent certs, human sponsor mapping, kill-switch SLA, and audit trail will own this domain for 5+ years. EOSE has the architecture (LOCO D11 design), the running infrastructure (openclaw in enterprise tenants), and the 12-month window. DCJ-037 is the filing.

REMEDIATION PRIORITY

ordered by impact · before any CTC security review

P0

D11 · Agent ID

File DCJ-037. Design EOSE Agent Identity Framework. PKI-backed agent certs, human sponsor mapping, kill-switch within 60s, audit trail. Start with openclaw agents in eose-entry namespace.

Kay + Amani + CLO

P0

D6 · Compute

Add ResourceQuota + LimitRange to ct-fac-system namespace. Use composer-crew namespace config as template. 1 hour to implement.

BOSUN · SRE

P0

ct-intel-pusher

Document what this CronJob pushes and where. 15-minute interval, 9+ days running, destination TBD. CLO must sign off before next billing cycle. This is a data flow audit item.

Amani · CLO

P1

D10 · Identity

Add Workload Identity to ct-fac-system ServiceAccounts. Annotate each SA with azure.workload.identity/client-id. Use pemos-system as template.

CODY · Build

P1

D3 · Images

Enforce image signing on eosefleetacrdev. Cosign key pair + OPA Gatekeeper policy requiring signed images in ct-fac-system. Cosign is free, OPA policy is 20 lines.

JOHN · OSS

P1

D2 · Network

Add PeerAuthentication STRICT to ct-fac-system. One manifest, 10 lines. All pod-to-pod in ct-fac-system requires mTLS. Currently relies on cluster-wide STRICT but namespace policy is missing.

BOSUN · SRE

P1

ct-builder-gateway

Pod Pending on CTC AKS for 12 days. Add nodeSelector for a10pool2 or h100pool2, or add tolerations for GPU spot nodes. The entry gate must be running before any CTC demo.

BOSUN · CODY

P2

D9 · GitOps

Add Flux Kustomization for ct-fac-system. Currently manual deploys. Flux GitRepository + Kustomization pointing at fleet-sync/k8s/ct-fac-system/.

JOHN · GitOps

P2

D7 · Logging

Add Azure Monitor Sentinel alert rules for ct-fac-system. Baseline: high error rate, unexpected external calls, resource quota breach, image pull failure.

RICK · Data

🌌 THE FOF UPGRADE — Flat Vector → PEMCLAU GraphRAG

The product pitch is now a security compliance argument. Wael's SecArch V5 section 5.4.2 (Knowledge Layer) explicitly requires embedding poisoning detection and validation against trusted references. ChatCTC's current MongoDB Atlas KB uses flat cosine similarity RAG. PEMCLAU uses 2-hop GraphRAG with causal graph topology. The difference is not performance — it is security posture.

The LOCO D11 compliance path runs through GraphRAG adoption. An agent with a verifiable identity (D11) operating on a verified knowledge graph (GraphRAG) with audit trails (D7) is a defensible enterprise AI posture. An agent with no identity operating on flat vector search with no validation is not.

CHATCTC — CURRENT (FLAT RAG)

PEMCLAU — UPGRADE (GRAPHRAG)

Flat cosine similarity · I(C;A) ≈ 0

2-hop graph expansion · 60-80 causally connected nodes

No embedding validation · poisoning possible

yone validator · every embedding γ₁-floor-checked

No agent identity · no audit trail per query

D11-ready · agent ID + human sponsor + query log

MongoDB Atlas KB · no graph topology

17,283 nodes · 80,979 edges · 4 edge types

D11: 0/10 (no framework)

D11: 8/10 (with AIF implementation)

WHAT TO BUILD NEXT

the LOCO Assessment Engine — from corpus to packaged product

P0 · SHIP THIS WEEK

Agent Identity Framework (AIF)

PKI-backed agent certs. Human sponsor registry. Kill-switch API. 60-second SLA. First enterprise to ship this owns D11 for 5 years. DCJ-037 is the filing. 12-month window from 2026-04-27.

P0 · THIS WEEK

ct-fac-system D6 ResourceQuota

One manifest. 10 lines. Blocks the single most embarrassing D6 gap before any CTC security audit. Use composer-crew namespace.yaml as the template.

P1 · THIS SPRINT

LOCO Assessment Engine v1

Packaged harness that takes an enterprise codebase + kubectl access + az CLI read-only and produces a D1–D11 scorecard with evidence. ARB1-LOCO-ENGINE-001 is the design.

P1 · THIS SPRINT

ct-intel-pusher Audit

15-minute CronJob, 9+ days, destination TBD. Document the data flow. CLO sign-off required. This is an Amani item — she needs to see what's being pushed and where before the next billing cycle.

P2 · NEXT SPRINT

PEMCLAU → ChatCTC Upgrade Proposal

Formal proposal to CTC: flat MongoDB Atlas KB → PEMCLAU GraphRAG. 2-hop expansion. Embedding validation. D11 compliance path. The FOF upgrade is now a security argument, not just a product pitch.

P2 · NEXT SPRINT

ct-builder-gateway Pending Fix

Add GPU node selector or toleration. 12 days Pending is too long. The entry gate must be running before any CTC demo. nodeSelector: agentpool: a10pool2 or h100pool2.