Skip to content

Bluefly Cloudflare Separation-of-Duties, Catalog, and Audit Plan

Status: Evidence-based audit plan; live Cloudflare inventory pending
Date: 2026-08-05
Scope: Bluefly-controlled Cloudflare accounts, zones, domains, subdomains, tunnels, routes, Access applications/policies, service tokens, DNS, TLS, logging, and infrastructure-as-code ownership

0. Live evidence — 2026-08-19

VERIFIED_CLOUDFLARE, pulled via Cloudflare API (account 49a0ccd36e52c791db29604e7fe3b793), read-only, this timestamp.

0.1 Zones (16 total)

16 zones exist on the account. 10 have a matching tunnel; 6 do not.

0.2 Tunnels (10, all healthy)

Tunnel UUID Connections Created
AgentBlu.ai 3ddcf302-b5bc-46f4-9945-9ffdd6c732a2 4 2026-03-19
BluTown.ai f0498257-e507-43ee-b8a8-6b542074dd5e 4 2026-06-25
BlueflyAgents.com f6da7bdf-d0f8-4796-a804-afb7984bbe11 8 2025-12-20
CoPaw.us 95c143a5-14fb-48eb-8557-5027cac7c496 4 2026-02-21
ContextControl.ai 775b5aac-0e5d-4301-b827-a9e98bda43d6 4 2026-04-08
ContractPlane.ai ee25a4c7-b8f6-414c-989e-68b24df5d680 4 2026-03-13
Drupl.ai cd718616-5613-49bd-b5c3-da5ee59b1be8 4 2026-03-07
NAS 9bc38f5f-de15-41eb-897f-fe7d97045c08 4 2026-03-06
OpenStandardAgents.org 9018affb-a7df-4cbc-9c38-403cd1a74370 4 2026-03-06
duadp.org dd115749-3c4d-422d-9b86-5ef42380704a 4 2026-03-28

BlueflyAgents.com runs double the connections of every other tunnel and is the oldest by 2+ months — consistent with it carrying auth.blueflyagents.com (see §0.4). Still NOT_ESTABLISHED: full consumer list of the 10.0.0.0/24 private route flagged in earlier drafts.

0.3 Status of this pass

Collected: zone list, tunnel list/health/connection-count, full or CNAME-scoped DNS for 423interactive.com, actprotectiveservices.com, agentblu.ai, blueflyagents.com, blutown.ai, contextcontrol.ai, contractplane.ai, copaw.us, drupl.ai, duadp.org, openstandardagents.org — 11 of 16 zones. Not yet pulled: bluefly.io, maineflyphish.com, openstandarduapd.org, universaldiscoveryprotocol.org, wornink.com (all 5 are out-of-scope/NOT_ESTABLISHED zones per §0.5, low priority); tunnel ingress rules, Access applications/policies, API/service token scopes, account members/roles, TLS/WAF settings. §4's nine-catalog reconciliation not yet performed. No mutation performed. No CSV deliverables produced.

0.4 Critical finding — tunnel names do not match hostname ownership

blueflyagents.com carries ~70 proxied CNAME records. The overwhelming majority (a2a-collector, agents, api, bk, brain, chat, code, compliance, dragonfly, gkg, grafana, kagent*, langflow, litellm, marketplace, mcp*, n8n, nas, openclaw, openstandard-ui, ossa-*, prometheus, router, studio, submolt*, webui, workflow, *.workspaces, and more) resolve to cd718616-5613-49bd-b5c3-da5ee59b1be8.cfargotunnel.com — the tunnel named "Drupl.ai", not "BlueflyAgents.com".

The tunnel actually named "BlueflyAgents.com" (f6da7bdf-...) only serves: agent-webhook, auth, blu, blutown, gascity, moshi, opencode, and the bare root.

Same pattern on contractplane.ai: the tunnel named "ContractPlane.ai" (ee25a4c7-...) only carries auth and www; the other 11 hostnames (api, app, chat, compliance, docs, evidence, inspect, policy, registry, status) all ride the Drupl.ai tunnel too.

docs.blueflyagents.com and source.blueflyagents.com are not tunneled at all — GitLab Pages and Fastly/Acquia respectively.

Also noted in agentblu.ai: a _duadp.agentblu.ai TXT record (v=duadp1 url=...) plus DKIM/SPF — this zone sends mail and participates in DUADP discovery, undocumented dependencies to check before any retirement.

Correction, 2026-08-19 (full drupl.ai DNS now pulled): the Drupl.ai tunnel legitimately serves its own zone too — 19 drupl.ai hostnames (app, auth, dashboard, dragonfly, fleet, market, marketplace, and dev variants). The name is not wrong for what it does for its own domain — the finding is narrower than "misleading name": this one tunnel is shared across three tenants (drupl.ai itself, ~65 blueflyagents.com hosts, ~11 contractplane.ai hosts) rather than being scoped to one. That's a shared-failure-domain question, not a rename question — renaming it wouldn't fix the actual issue, which is whether drupl.ai, blueflyagents.com, and contractplane.ai traffic should share one tunnel's blast radius and credential. Proposed name agent-platform-primary in §0.7 reflects that it's a shared platform tunnel, not that "Drupl.ai" was a mistake.

0.5 Zone ownership corrections — operator-authoritative, 2026-08-19

The tunnel-less zones are not one bucket. Each classified individually per direct owner statement:

Zone Owner class Business/technical owner Hosting Cloudflare role Tunnel required Audit scope Mutation authorized Notes
actprotectiveservices.com CUSTOMER Customer (not Bluefly) Not established DNS only NO EXCLUDED — do not touch NO Hard stop. No DNS, tunnel, Access, token, origin, redirect, nameserver, or IaC-import work without explicit separate customer-scoped authorization.
423interactive.com PERSONAL_PORTFOLIO Thomas Cloudways DNS + proxy NO Excluded from agent-platform cleanup NO Personal site, unrelated to platform work.
bluefly.io BLUEFLY_CORPORATE Bluefly Cloudways (current) DNS + proxy NO Active migration, tracked separately NO — cutover only, not audit cleanup Live: gitlab.com/blueflyio/assets/bluefly. Rebuild in progress: gitlab.com/blueflyio/assets/bluefly.io. Do not touch DNS/origin until rebuild replaces Cloudways origin.
openstandardagents.org BLUEFLY_PRODUCT Bluefly / OSSA GitLab Pages DNS + TLS edge, proxying optional NOT_ESTABLISHED — has a tunnel entry in §0.2 but role vs. Pages unconfirmed In scope, needs DNS-record proof (§0.6) NO — pending proof Do not assume tunnel-owned. Website source/deploy is a separate GitLab project; Cloudflare's only proven role so far is DNS.
duadp.org BLUEFLY_PRODUCT Bluefly / DUADP GitLab Pages DNS + TLS edge, proxying optional NOT_ESTABLISHED — same as above In scope, needs DNS-record proof NO — pending proof Same caveat as openstandardagents.org.
maineflyphish.com NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NO Excluded until owner states purpose NO Not yet addressed by operator.
universaldiscoveryprotocol.org NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NO Excluded until owner states purpose NO Not yet addressed by operator.
openstandarduapd.org NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NO Excluded until owner states purpose NO Suspected defensive typo-squat registration, unconfirmed.
wornink.com NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NO Excluded until owner states purpose NO Not yet addressed by operator.

Hard stops in force: no mutation of any kind on actprotectiveservices.com or 423interactive.com under this or any future pass of this audit unless the operator explicitly re-scopes them. bluefly.io DNS/origin changes belong to the rebuild-cutover project, not this cleanup.

0.6 GitLab Pages zones — DNS proof required before tunnel classification

openstandardagents.org and duadp.org both appear in the live tunnel list (§0.2) with a tunnel of the same name. That does not prove the tunnel is what serves the website — GitLab Pages custom domains typically point at Pages' own CNAME target, not a Cloudflare tunnel. Required before either can be marked TUNNEL_REQUIRED=NO:

  • DNS_RECORD (A/CNAME at zone apex and any subdomains)
  • TARGET (Pages CNAME target vs. *.cfargotunnel.com)
  • PROXIED (orange-cloud on/off)
  • GITLAB_PAGES_CUSTOM_DOMAIN (confirmed configured in the GitLab project)
  • TLS_OWNER (Cloudflare edge cert vs. GitLab Pages Let's Encrypt)
  • CLOUDFLARE_TUNNEL_INVOLVED (yes/no, and if yes, what specifically routes through it)
  • CLOUDFLARE_ACCESS_INVOLVED (yes/no)

RESOLVED, 2026-08-19. Both zones' root and www CNAME to *.gitlab.io (duadp.org/www.duadp.org → blueflyio.gitlab.io; openstandardagents.org/www → openstandardagents.gitlab.io), unproxied. GitLab Pages confirmed as the owner of the marketing/docs site for both.

But each zone's same-named tunnel is also legitimately live — not dead, not a naming artifact:

  • openstandardagents.org tunnel (9018affb-...) serves compliance.openstandardagents.org and studio.openstandardagents.org — app subdomains, separate from the Pages site.
  • duadp.org tunnel (dd115749-...) serves compliance, discover, register, telemetry — same pattern.

Correct classification: GitLab Pages and the Cloudflare tunnel coexist, each owning different hostnames in the same zone. Neither should be retired to "fix" the other; this is not a conflict, it's a zone shared by two origins. openstandardagents.org also carries a _duadp.openstandardagents.org TXT record (DUADP node-verification) and its own SPF/DKIM/MX — participates in mail + DUADP discovery, same as agentblu.ai.

0.7 Tunnel rename decision table — PROPOSAL ONLY, EXECUTE_NOW=NO for every row

Built from live DNS pulls in §0.2–§0.4 (6 of 10 tunnels have verified hostname mappings so far).

Tunnel ID Current name Verified hostnames Current name accurate? Proposed name IAC owner Approval required Execute now
cd718616-... Drupl.ai Own zone (19 drupl.ai hosts) + ~65 blueflyagents.com hosts + ~11 contractplane.ai hosts Accurate for its own zone; incomplete picture for the other two tenants it also carries agent-platform-primary (proposed — reflects shared-tenant role, not a "wrong name" correction) NOT_ESTABLISHED — Cloudflare Terraform repo not yet located YES NO
f6da7bdf-... BlueflyAgents.com root, agent-webhook, auth, blu, blutown, gascity, moshi, opencode Partially accurate — carries auth for the brand, not the brand's other hosts No rename proposed NOT_ESTABLISHED YES NO
ee25a4c7-... ContractPlane.ai auth, www only (2 of 13 contractplane.ai hosts) NO — misleading, most of the brand's traffic rides Drupl.ai instead contractplane-auth (proposed) NOT_ESTABLISHED YES NO
775b5aac-... ContextControl.ai root, compliance, dev, source Accurate No rename needed N/A N/A NO
95c143a5-... CoPaw.us root, api, auth, blu, claw, compliance, discover, fm, mcp Accurate No rename needed N/A N/A NO
f0498257-... BluTown.ai api, dash, docs only (most "BluTown" traffic likely rides blutown.blueflyagents.com on Drupl.ai instead) Partially accurate No rename proposed — needs cross-zone reconciliation NOT_ESTABLISHED YES NO
3ddcf302-... AgentBlu.ai root, app, blu, compliance, jan Accurate No rename needed N/A N/A NO
9bc38f5f-... NAS NOT_ESTABLISHED — not yet pulled NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NOT_ESTABLISHED NO
9018affb-... OpenStandardAgents.org compliance, studio (root/www are GitLab Pages, unproxied, not this tunnel) Accurate — name matches, just narrower scope than the whole zone No rename needed N/A N/A NO
dd115749-... duadp.org compliance, discover, register, telemetry (root/www are GitLab Pages, unproxied, not this tunnel) Accurate — same pattern No rename needed N/A N/A NO

IaC authority located and root cause found, 2026-08-19. blueflyio/agent-platform/infra/iac, terraform/cloudflare-tunnel/ (generic reusable module) and terraform/cloudflare/tunnels.tf (the actual blueflyagents.com/drupl.ai route list — content closely matches the live ingress pulled in §0.8a). But the resource block that would actually apply it (cloudflare_zero_trust_tunnel_cloudflared_config) is commented out, with an explicit TODO: the CI Cloudflare API token only has DNS-management scope, not Account > Cloudflare Tunnel > Edit. Terraform has never actually managed live tunnel ingress config — it's been dashboard-only since this file was written. This is the root cause of §0.9's duplicate/stale-rule finding: there is no applied source of truth for anything to drift from or converge to. Rename-in-place vs. tunnel-recreation-with-new-credentials remains unproven and moot until this is fixed — a rename via Terraform can't be tested when Terraform can't write to tunnel config at all.

Blocked externally, not a source problem: closing this gap needs a Cloudflare API token with Account > Cloudflare Tunnel > Edit scope, issued through 1Password by the Cloudflare account owner. Not something resolvable from source/CI alone.

0.8a Tunnel ingress configuration — pulled for NAS, BlueflyAgents.com, Drupl.ai (2026-08-19)

DNS shows which tunnel a hostname is CNAME'd to. It does not show whether that tunnel's ingress config actually has a matching rule, or whether other tunnels carry stale rules for hostnames they no longer serve. Pulled cfd_tunnel/{id}/configurations for the three most consequential tunnels to check.

Critical finding — the "BlueflyAgents.com" tunnel's ingress config (~90 rules) includes hostnames for agentblu.ai, contextcontrol.ai, contractplane.ai, drupl.ai, copaw.us, and openstandardagents.org — zones whose DNS §0.4 already confirmed CNAME to other, differently-named tunnels. Cloudflare only ever consults the ingress rules of the tunnel a hostname's DNS actually points to, so these are dead/unreachable config, not active routing — but their presence means whoever maintains this tunnel's config has been copying or accumulating rules across tunnel boundaries rather than keeping one hostname → one tunnel → one ingress-rule mapping. This is exactly the kind of drift the separation-of-duties model in §3 is meant to prevent (public-hostname mapping is supposed to be service-owner-proposed, platform-owner-approved, one rule per hostname) — evidence this hasn't been enforced in practice.

NAS tunnel (9bc38f5f-...): fully mapped, 14 ingress rules, explicit http_status:404 catch-all present (correct — no wildcard fallback to an origin). Exposes: DSM (5001, TLS-noverify), MinIO (9000/9001), code-server (8080), Dockge (9010), private npm registry (4873), CouchDB/Obsidian sync (5984), Zotero (5006, TLS-noverify), Flowise (3100), Langfuse (3150), LiteLLM (4050), a workspaces wildcard (*.workspaces.blueflyagents.com → 30443), and one hop to blueflynas.tailcf98b3.ts.net:3045 for happy.blueflyagents.com. Two origins skip TLS verification (noTLSVerify: true) — not yet evaluated whether that's justified or a gap. Access-policy coverage for these hostnames not yet pulled (§0.9 below).

Drupl.ai tunnel (cd718616-...): 16 ingress rules, http_status:404 catch-all present. Confirms §0.7's correction — this tunnel serves its own drupl.ai hosts directly on localhost, but several dev-* hostnames backhaul over Tailscale to two different hosts: blueflynas.tailcf98b3.ts.net (dev/dev-app/dev-marketplace-app) and oracle-platform.tailcf98b3.ts.net (dev-dragonfly/dev-dragonfly-api). So this one tunnel's origins span three physical hosts (local, NAS, Oracle) — the "shared blast radius" concern from §0.7 is broader than just multi-tenant DNS, it's multi-host origin fan-out too.

BlueflyAgents.com tunnel (f6da7bdf-...): the live, reachable rules (matching DNS from §0.4) are agent-webhook, auth, blu, blutown, gascity, moshi, opencode plus the bare root — everything else in its ~90-rule ingress list is stale per the finding above. warp-routing: enabled: true on this tunnel specifically (the other two have it disabled) — consistent with the 10.0.0.0/24 private route flagged since the original plan draft; still NOT_ESTABLISHED which service(s) actually consume that WARP route.

Remaining 7 tunnels pulled, 2026-08-19 — all ingress configs now collected (10/10).

Tunnel Rule count Matches DNS? WARP
AgentBlu.ai 6 + catchall Yes, exact match, all clean off
ContextControl.ai 4 + catchall Yes, exact match, all clean off
BluTown.ai 4 + catchall Adds gc.blutown.ai — a hostname §0.4's DNS pull didn't have (needs re-check) off
OpenStandardAgents.org 2 + catchall Yes, matches compliance/studio from §0.6 off
duadp.org 4 + catchall Yes, matches compliance/discover/register/telemetry from §0.6. NOTE: discover.duadp.org → localhost:4201 is a known production routing pattern requiring the origin daemon to be running. off
ContractPlane.ai 11 + catchall NO — configured for api, chat, root, www, app, docs (×2, duplicate rule), compliance, evidence, registry. DNS (§0.4/§0.7) only CNAMEs auth+www to this tunnel; the rest of these rules are stale/unreachable, same pattern as BlueflyAgents.com. off
CoPaw.us 94 + catchall NO — near-duplicate of the BlueflyAgents.com tunnel's ~90-rule config. Lists rules for agentblu.ai, contextcontrol.ai, contractplane.ai, drupl.ai, the full blueflyagents.com app suite, and its own copaw.us hosts. Only the copaw.us rules are DNS-live (§0.4); everything else is dead config. off

0.9 Critical risk — hostname routing has no single source of truth

This is the load-bearing finding of this audit pass, more significant than any individual tunnel's name. At least four tunnels — BlueflyAgents.com, CoPaw.us, ContractPlane.ai, and to a lesser extent Drupl.ai — carry large, overlapping ingress rule sets covering hostnames across nearly the entire agent-platform surface (agentblu.ai, contextcontrol.ai, contractplane.ai, drupl.ai, copaw.us, blueflyagents.com). The BlueflyAgents.com and CoPaw.us configs in particular are near-identical, ~90-rule copies of each other.

DNS is the only thing currently deciding which of these duplicate configs is actually live for a given hostname (§0.4/§0.7/§0.8a). There is no technical control preventing a hostname's DNS CNAME from being repointed — by typo, automation error, or a well-intentioned "quick fix" — to one of these other tunnels that already has a matching (but stale/wrong) ingress rule ready to serve it. Unlike pointing a hostname to a tunnel with no matching rule (which fails with the 404 catch-all, safely), pointing it to one of these duplicate-config tunnels would silently succeed and route to whatever origin port that stale rule specifies — which may be the wrong service, an old port number, or a decommissioned host.

This reframes the audit's priority: the tunnel-rename question (§0.7) is cosmetic next to this. Before any rename or consolidation work, the duplicate ingress configuration itself needs to be understood and cleaned — specifically:

  • how did four tunnels end up with overlapping full-platform rule sets (shared deployment script? copy-paste bootstrap? one tunnel's config cloned to create the others?);
  • which tunnel's copy of each duplicated rule set is the "canonical" one being kept in sync (if any), and which are simply abandoned snapshots;
  • whether removing the dead rules from the non-live tunnels is safe now, or whether some other automation still writes to them.

Not yet established — needs its own evidence pass, separate from this one: the actual origin ownership/deployment history that produced this duplication.

0.10 Access / token scope — BLOCKED, external permission gap

Attempted: GET /accounts/{account}/access/apps, GET /user/tokens. Both returned Unauthorized to access requested resource (Cloudflare error 9109) — the OAuth grant this session authenticated with does not include Access or token-management read scope, distinct from the zone/tunnel/DNS scope that has been working throughout this pass. This is an external-authority permission gap, not a bug: re-authorizing the Cloudflare API connection with a broader scope (or reading Access/token config from the dashboard directly) is required before §4.4's Access catalog or the token-scope portion of §12's risk register can be completed. Recorded here rather than worked around.

0.11 TLS/zone settings — partial, blueflyagents.com only

Pulled settings/ssl and settings/min_tls_version for blueflyagents.com (the highest-priority zone per §0.2's connection-count finding). Two gaps against this plan's own §10 acceptance criteria ("every production tunnel... Full (strict)"):

  • ssl_mode: full, not full_strict. Full mode still validates that the origin presents a certificate, but does not validate that it's issued by a trusted CA or matches the hostname — an on-path attacker between Cloudflare and the origin (including anything transiting the Tailscale hops documented in §0.8a) could present any cert. Should be strict for a production agent-platform surface.
  • min_tls_version: 1.0. TLS 1.0/1.1 are deprecated (RFC 8996) and typically disabled by default on modern Cloudflare zones — this being at 1.0 suggests either an old zone default that was never tightened, or a legacy client dependency that hasn't been identified. Should be 1.2 minimum absent a proven reason otherwise.

Remaining 15 zones pulled, 2026-08-19 — TLS settings now complete for all 16 zones.

Zone SSL mode Min TLS
423interactive.com flexible (weakest — no origin TLS at all) 1.0
actprotectiveservices.com strict (customer zone, already correctly configured — not this audit's doing) 1.0
agentblu.ai, blutown.ai, contextcontrol.ai, contractplane.ai, copaw.us, drupl.ai, duadp.org, openstandardagents.org, openstandarduapd.org, universaldiscoveryprotocol.org, wornink.com, maineflyphish.com, blueflyagents.com (§0.11) full 1.0
bluefly.io full 1.2 — the one zone already correct

Finding: min_tls_version: 1.0 is an account-wide condition, not per-zone drift — 15 of 16 zones share it, including every agent-platform zone. This is one setting to check/fix, not sixteen. bluefly.io being the sole exception suggests whoever built that zone (or its Cloudways-era setup) explicitly set 1.2, while the rest inherited an old account default that's never been revisited.

423interactive.com (personal, out of scope per §0.5) is the only zone on flexible SSL — Cloudflare-to-origin traffic is cleartext. Not touching it (personal site), but noting it for completeness since the pull already covered it.

Not yet pulled: WAF/firewall rules, cache rules, redirect rules, registrar/expiry data for any zone.

0.12 DNSSEC status — all 16 zones

disabled on 15 of 16 zones, including every agent-platform zone. 423interactive.com (personal) is active. bluefly.io is pending (consistent with the in-progress rebuild — likely mid-cutover DS-record propagation, not a stalled/broken state).

Lower severity than §0.9/§0.11 — DNSSEC protects against DNS-response spoofing/cache poisoning upstream of Cloudflare's own authoritative resolution, a smaller attack surface than the TLS-mode and duplicate-ingress-config findings. Worth enabling account-wide as part of any future hardening pass, not urgent on its own.

0.8 Scope discipline

This tunnel-naming defect is the most visible finding so far. It is not proof that Access policy, token scope, origin exposure, DNS ownership breadth, TLS mode, logging, or IaC-authority gaps (§§3–5 below) can wait indefinitely — those remain open and unaudited this pass. Naming is being worked first because it's a prerequisite for making any other decision about these tunnels correctly, not because it's the only real problem.

1. Executive finding

The supplied Cloudflare dashboard evidence establishes ten healthy cloudflared tunnels, each connected for approximately six days:

Tunnel Type Private route shown Observed state
AgentBlu.ai cloudflared None shown Healthy
BluTown.ai cloudflared None shown Healthy
BlueflyAgents.com cloudflared 10.0.0.0/24 Healthy
CoPaw.us cloudflared None shown Healthy
ContextControl.ai cloudflared None shown Healthy
ContractPlane.ai cloudflared None shown Healthy
Drupl.ai cloudflared None shown Healthy
NAS cloudflared None shown Healthy
OpenStandardAgents.org cloudflared None shown Healthy
duadp.org cloudflared None shown Healthy

This proves connector health only. It does not prove that DNS records, public hostnames, ingress rules, origins, Access policies, TLS settings, credentials, ownership, logging, or tunnel boundaries are correct.

The present naming strongly suggests one tunnel per brand/domain, but that is not yet a proven security or availability requirement. The target is not an arbitrary reduction in tunnel count. The target is the smallest set of failure domains justified by environment, trust boundary, origin network, and operational ownership.

2. Authoritative architectural constraints

The delivered Bluefly governance material establishes:

  • Cloudflare owns public ingress and Zero Trust enforcement; Bluefly must not build a competing reverse proxy or ingress platform.
  • Cloudflare Tunnel is the only public ingress path for services that must be internet-reachable.
  • Tailscale is the private administrative path. Public ingress and private administration must remain separate.
  • Oracle is production. Changes must be made through the established infrastructure-as-code and deployment authority, not by ad hoc edits on Oracle.
  • Bluefly owns composition, topology, secrets wiring, governance, verification, and operational conventions.
  • Gas City is the upstream orchestration runtime; OpenClaw is the messaging gateway; Dolt is the state ledger.
  • blu-city is the Gas City runtime/deployment identifier. BluTown / blutown.ai is the broader operations/product surface.

The nine requested catalog files at blueflyio/blu/blucity-docs/Engineering-Standard/catalog/ were not delivered into this session. Their Cloudflare-specific claims and ownership assignments remain NOT_ESTABLISHED here and must be read before the audit is treated as complete.

3. Separation-of-duties model

Duty Accountable authority Permitted actions Prohibited combination
Domain registration Business/domain owner Registrant, renewal, registrar lock, recovery Must not depend on the same credential used for daily DNS changes
Cloudflare account ownership Thomas / designated executive owner Membership, break-glass recovery, billing Not used for routine deployment
DNS and zone policy Platform/IaC maintainers Reviewed DNS, zone settings, DNSSEC, certificate policy Application deployers do not receive unrestricted account DNS write
Tunnel lifecycle Platform/IaC maintainers Create/retire connectors and routes through code Application repos do not create unmanaged tunnels
Public-hostname mapping Service owner proposes; platform owner approves Map hostname to registered service/origin No hostname without catalog owner and deployment evidence
Access policy Security/governance owner approves Identity, group, device posture, service-auth rules Tunnel operator cannot unilaterally grant human access
Origin service deployment Service/repository owner Deploy the origin via existing CI Cannot modify Cloudflare policy outside governed IaC
Secrets 1Password/established secret authority Issue, rotate, revoke, inject No tokens in Git, catalog docs, shell receipts, or tunnel JSON exports
Audit and verification Librarian/auditor, read-only Inventory, reconcile, evidence, exceptions Auditor does not approve or execute their own corrections
Emergency response Named incident commander + break-glass approver Time-bounded containment with retrospective No permanent unreviewed emergency configuration

Minimum role design:

  1. Two human account owners for recovery continuity; hardware-backed MFA; no shared daily-use login.
  2. Read-only audit role for the Librarian.
  3. Scoped DNS/tunnel automation token for CI, limited to named zones and required resources.
  4. Separate Access-policy administration role.
  5. Application teams receive no broad Cloudflare account token.
  6. Break-glass credentials are sealed, monitored, tested, and not used by automation.

4. Required authoritative catalogs

4.1 Domain catalog

One row per registered domain, including parked and defensive domains:

domain, registrar, registrant entity, business owner, technical owner, Cloudflare account, zone ID, nameserver status, registration expiry, auto-renew, registrar lock, DNSSEC, email use, product/platform mapping, lifecycle, evidence timestamp.

4.2 Subdomain and DNS catalog

One row per DNS name and wildcard, including records not proxied through Cloudflare:

fqdn, zone, record type, target fingerprint/redacted destination, proxied, TTL, purpose, environment, exposure class, product, platform, capability, repository, deployment, service owner, data classification, authentication, Access application, tunnel, public hostname rule, origin service, health check, last observed request, lifecycle, IaC source, evidence.

Allowed lifecycle values: ACTIVE, CANDIDATE, DEPRECATED, PARKED, UNKNOWN, REMOVE_AFTER_APPROVAL.

Allowed exposure classes:

  • PUBLIC_ANONYMOUS
  • PUBLIC_AUTHENTICATED
  • PARTNER_OR_FEDERATED
  • MACHINE_TO_MACHINE
  • EMPLOYEE_ZERO_TRUST
  • PRIVATE_TAILNET_ONLY
  • NOT_ESTABLISHED

4.3 Tunnel and route catalog

One row per tunnel, connector, public-hostname rule, and private-network route:

tunnel name, tunnel UUID, environment, origin network, host, connector count, connector IDs, connector versions, HA placement, public hostnames, private CIDRs, WARP routing use, credentials authority, token last rotated, IaC authority, service owner, logs, SLO, last connection, replacement tunnel, retirement state.

4.4 Access catalog

application, hostname/path, audience, identity provider, allow rules, deny rules, service tokens, session duration, device posture, bypass rules, CORS, owner, last review, evidence.

Every bypass and Everyone rule requires an explicit, dated exception.

5. Mandatory evidence collection

Export read-only evidence before changing anything:

  1. Cloudflare accounts, members, roles, API tokens, token scopes, service tokens, and audit-log retention.
  2. Every zone and registrar relationship; nameservers; DNSSEC; domain expiry and lock state.
  3. Complete DNS record export for every zone, including wildcards, mail records, verification records, CAA, and unproxied records.
  4. Every tunnel, tunnel UUID, connector, connector version, origin host, public-hostname ingress rule, catch-all rule, and private route.
  5. Every Access application and policy, identity provider, group, device-posture rule, bypass, service-auth policy, and session lifetime.
  6. Zone settings: SSL/TLS mode, minimum TLS, HSTS, Always Use HTTPS, origin certificates, certificate packs, mTLS, WAF, rate limiting, bot controls, cache rules, redirects, Workers routes, Pages/custom hostnames, email routing, and log destinations.
  7. Existing IaC in the authoritative repository, including domains.yaml and Cloudflare Terraform noted in prior evidence.
  8. Deployed cloudflared topology on Oracle/NAS using read-only inspection only: process/container identity, version, config source, credential source path (not value), replicas, restart policy, and bound origins.
  9. Request evidence for 30/60/90 days where available: last traffic, status distribution, origin errors, Access denials, and unused hostname candidates.
  10. Repository and deployment mapping for every hostname using the nine Engineering Standard catalogs.

All evidence must be timestamped and classified as VERIFIED_CLOUDFLARE, VERIFIED_IAC, VERIFIED_DEPLOYMENT, VERIFIED_CATALOG, PROPOSED, or NOT_ESTABLISHED.

6. Audit tests for every subdomain

For each FQDN, answer with evidence:

  1. Does it exist in authoritative DNS?
  2. Is it owned by a cataloged product/platform/capability?
  3. Is the target alive and intended?
  4. Is it proxied? If not, is the origin IP exposed and justified?
  5. Does it use the correct tunnel and origin service?
  6. Is there a dangerous wildcard or catch-all ingress rule?
  7. Is authentication appropriate for the exposure class?
  8. Does Cloudflare Access fail closed?
  9. Are service-to-service calls using service authentication rather than human bypass?
  10. Is TLS Full (strict) with valid origin trust?
  11. Is the origin reachable directly from the internet?
  12. Are administrative paths (/admin, dashboards, metrics, health detail, APIs) protected or private?
  13. Are CORS, cache, redirects, WAF, and rate limits intentional?
  14. Does the hostname appear in exactly one IaC authority?
  15. Is it duplicated, shadowed, stale, typo-squatted internally, or superseded?
  16. Does it have recent traffic or a documented reason to remain idle?
  17. Can it be removed without breaking email, verification, federation, callbacks, or certificates?

No record may be deleted based only on zero recent traffic.

7. Initial domain/tunnel hypotheses requiring proof

Surface Likely role from supplied governance Audit priority Current classification
blutown.ai Operations/product surface; dash.blutown.ai is a known production dashboard route P0 Partially verified from supplied evidence
blueflyagents.com Marketplace/agent ecosystem; only supplied tunnel with 10.0.0.0/24 private route P0 Private route verified; scope/need not established
duadp.org DUADP discovery/publishing authority P0 Product role verified; routing not established
openstandardagents.org OSSA specification/contract surface P0 Product role verified; routing not established
contextcontrol.ai Primary product surface/shared-context product P0 Product role verified; routing not established
contractplane.ai Control-plane surface P0 Product role verified; routing not established
drupl.ai Drupal-related surface; dragonfly.drupl.ai referenced as an internal gate P1 Claims require current catalog verification
agentblu.ai Agent Blu branded surface P1 Ownership and deployment not established
copaw.us CoPaw surface P1 Ownership and deployment not established
NAS Infrastructure-named tunnel P0 Public-hostname and origin exposure not established

The NAS tunnel deserves immediate review: infrastructure identity is not a customer-facing ownership boundary, and no NAS administrative surface should be public merely because the tunnel is healthy.

8. Target tunnel architecture

Do not consolidate by domain name alone. Group only when all of these match:

  • environment and blast radius;
  • origin network/host;
  • operational owner;
  • credential authority and rotation cadence;
  • availability/SLO;
  • change/deployment lifecycle;
  • data and access classification.

Recommended decision pattern:

  • Keep separate production tunnels for genuinely separate origin networks or failure domains.
  • Use multiple connectors on a tunnel for high availability when they serve the same failure domain.
  • Use public-hostname ingress rules for multiple related hostnames on one origin network when this does not enlarge credential or operational blast radius.
  • Keep private CIDR routing separate from public application ingress unless the documented WARP/private-routing design requires the same tunnel and security review approves it.
  • Do not route broad 10.0.0.0/24 merely for one service. Replace with the smallest justified CIDR or hostname/private-network design after consumer discovery.
  • End every ingress configuration with an explicit non-routing catch-all.
  • Keep administrative services tailnet-only unless a documented Access-protected requirement exists.

Potential end state (proposal, not fact): tunnels organized as prod-oracle-public, prod-nas-public only if needed, prod-private-warp only if needed, plus separately justified non-production tunnels. Brand domains become hostname rules, not automatic tunnel boundaries.

9. Cleanup and optimization waves

Wave 0 — Freeze and preserve

  • Freeze ad hoc dashboard edits, tunnel creation, DNS deletion, and connector token sharing.
  • Back up Cloudflare configuration and IaC state without secrets.
  • Establish the current-state evidence bundle and change ledger.

Wave 1 — Reconcile authority

  • Read all nine Engineering Standard catalogs.
  • Reconcile Cloudflare objects to product, platform, capability, repository, deployment, pack, and document owners.
  • Mark every unmatched object ORPHANED or NOT_ESTABLISHED; do not delete it.

Wave 2 — Close security gaps

  • Remove global/account-wide automation tokens in favor of scoped tokens.
  • Require MFA and least-privilege roles.
  • Enforce Full (strict) TLS, origin isolation, appropriate Access policy, and log coverage.
  • Eliminate public origin reachability and undocumented Access bypasses.
  • Review the 10.0.0.0/24 route and the NAS tunnel first.

Wave 3 — Normalize names and IaC

  • Adopt stable, environment/origin-based tunnel names.
  • Make the existing authoritative IaC repository the only write authority.
  • Import existing Cloudflare objects into state; do not recreate live objects blindly.
  • Add validation preventing duplicate FQDNs, unowned records, broad CIDRs, wildcard ingress, absent catch-all, and unprotected admin paths.

Wave 4 — Consolidate safely

  • Build a route-by-route migration matrix.
  • Create replacement connectors through reviewed CI.
  • Run old and new paths in parallel where supported.
  • Validate DNS, TLS, Access, origin isolation, application health, callbacks, federation, and logs.
  • Shift one hostname at a time with rollback criteria.

Wave 5 — Retire stale objects

  • Require service-owner and platform-owner approval.
  • Preserve rollback metadata and evidence.
  • Revoke old tunnel credentials only after the observation window.
  • Delete obsolete DNS/tunnels only through reviewed IaC.

10. Acceptance criteria

The program is complete only when:

  • 100% of registered domains and DNS records are cataloged.
  • 100% of proxied hostnames map to exactly one tunnel rule, origin, repository, deployment, and accountable owner.
  • 100% of tunnels and routes are represented in authoritative IaC.
  • 0 undocumented wildcards, catch-all proxies, Access bypasses, or public admin surfaces remain.
  • 0 exposed origin IPs remain without explicit exception.
  • 0 broad account tokens are used by application CI.
  • Every private route has a consumer and least-scope justification.
  • Every production tunnel has documented HA, health, logging, credential rotation, and rollback.
  • Every removal has owner approval and a retained evidence record.
  • A second read-only auditor can reproduce the inventory and reach the same conclusions.

11. Required outputs

  1. cloudflare-domain-catalog.csv
  2. cloudflare-subdomain-dns-catalog.csv
  3. cloudflare-tunnel-route-catalog.csv
  4. cloudflare-access-policy-catalog.csv
  5. cloudflare-rbac-token-matrix.md
  6. cloudflare-orphan-and-risk-register.md
  7. cloudflare-consolidation-decision-record.md
  8. cloudflare-change-and-rollback-plan.md
  9. Redacted evidence bundle with timestamps and source classifications

12. Hard stop conditions

Stop before mutation if any of the following is not established:

  • authoritative IaC repository and state;
  • exact Cloudflare account/zone ownership;
  • production versus non-production origin;
  • service owner;
  • direct-origin reachability;
  • Access dependency;
  • email, federation, OAuth, webhook, certificate, or verification dependency;
  • rollback target;
  • credential rotation authority.

No production mutation is authorized by this plan. It is the evidence and control framework required to propose a safe, reviewable cleanup.